Support for experimental ".mjs" output #23678
Conversation
|
|
|
Here are some notes if you are interested in using this PR meanwhile: https://gist.github.com/smotaal/4f9458cf43cd7a55a12d5c476c15400e |
|
We are waiting on node to formalize their support for ES6 modules. I do not think we know if you want .mjs to be the default output (as in this PR) as of yet. |
|
@mhegazy This is intended as a highly experimental step to allow the rest of us in this space to at least explore and experiment, if not to actually be able to do our part in uncovering other less popular edge cases. I realize TypeScript is working hard, but without this very minimal-no-promises-and-just-temporary feature, you are loosing out on all the far more significant potential that other TypeScript users out there could have been bringing to the table (and this is my little contribution) |
|
@mhegazy and yeah, I'm a much bigger fan of MJS music thank you (but the alternative is custom loader and so far this needs to be a CLI flag 😱) [this is how we users feel, we go where we are able/forced to] |
:D i wish there was that kind of feature.. if a feature is part of the product, ppl will use it and expect it to work, and will be unhappy when their build breaks if the behavior changes. |
|
Just to be clear, if .mjs ends up the default for node, we will support it. The node implementation details are not finalized at the moment. and we do not think we should be making any changes until node plans are stable and clear. We have two team members on the node modules working group, and we are closely following the development of node module implementation. |
|
So let me pick your brain on a temporary workaround for the following: What would be the most ideal way today to be able to augment my TypeScript development experience in Visual Studio Code so that it would allow me to work with Honestly, I've been racking my brain and others' to solve this, without adding a new layer of the very likely to cause even more incompatibility tomorrow but works today stuff that got us in this desperate mess we are in today. |
|
The feature is not supported, that is what #18442 tracks. As i mentioned earlier, we continue to monitor developments on the node side, and we will be adding support as that node module implementation materializes. |
|
Thanks for your contribution. This PR has not been updated in a while and cannot be automatically merged at the time being. For housekeeping purposes we are closing stale PRs. If you'd still like to continue working on this PR, please leave a message and one of the maintainers can reopen it. |
Partially Fixes #18442
This PR addresses two aspects of supporting the actual ".mjs" extension:
It allows TypeScript to resolve bare specifiers for a file when a respective ".mjs" file can be found, by first looking for a ".mjs" immediately before looking for a ".js" (without affecting any other order).
It allows TypeScript to output to ".mjs" only under the following very restrictive config:
{ "compilerOptions": { "module": "esnext", "target": "esnext", "allowSyntheticDefaultImports": true, "esModuleInterop": true } }Aside from changes to the source, both harness and baselines have changed to accommodate those two changes, with all current tests passings.
Thanks